Beverage dispensation systems are frequently utilized by servers in bars, restaurants, and other point-of-sale (POS) locations to facilitate the pouring of beverages into glasses and other containers for customer purchase and consumption. Such systems are generally capable of dispensing a selection of different beverages (e.g., beers, sodas, etc.), thus enabling fulfillment of a large number and variety of beverage orders in an efficient and timely manner. Servers and/or the business proprietor may manually monitor the volume of beverages dispensed (e.g., by tallying the number of glasses of each beverage sold) for a variety of purposes, including inventory tracking and pour cost analysis. Monitoring beverage dispensation in this manner, however, is difficult to perform in real time and may not provide an acceptably accurate indication of dispensed beverage volumes. For example, such methods cannot detect or otherwise account for problems such as server errors (e.g., overfilling, wastage), pricing discrepancies, unauthorized consumption, and unregistered sales. By some estimates, these problems may cause dispensed beverage volumes to be underreported by 10-25%. Monetary losses due to such problems at a single POS may be substantial and, when compounded across the POS locations of a large business enterprise (e.g., a national restaurant chain), may be on the order of millions of dollars. To address these and other problems, flow meter systems for automatically measuring and totaling beverage volumes as they are dispensed have been developed for use in conjunction with beverage dispensation systems.
FIG. 1 illustrates a schematic diagram of a conventional flow meter system 5 for monitoring beverage dispensation. The system 5 includes a plurality of flow meter devices (FMDs) 10, a signal conditioning device (SCD) 15, and a flow computation device (FCD) 20. Typically, devices 10, 15, 20 are purchased in the form of a prepackaged flow meter subsystem 25, such as the Harpagon flow meter subsystem sold by Auper Electronic Controls Inc., Quebec, Canada. The flow meter system 5 further includes a host computer 30 for use with the flow meter subsystem 25 and is typically purchased separately therefrom.
The FMDs 10 are typically of a turbine design and configured for in-line attachment to the piping of a beverage dispensation system (not shown) such that each beverage flows through a corresponding FMD 10 prior to being dispensed. Each FMD 10 outputs an analog voltage pulse signal responsive to the beverage flow therethrough. For a given FMD 10, the pulse frequency of the output signal is indicative of the beverage flow rate, and the total number of pulses of the output signal, when accumulated, is indicative of the total beverage flow.
The SCD 15 is in communication with the FMDs 10 and receives the respective output signals therefrom. Signal conditioning circuitry (not shown) within the SCD 15 may convert each FMD 10 signal into a corresponding discrete output signal (e.g., a square wave voltage signal) of a frequency equal to that of the FMD 10 signal and having voltage levels suitable for subsequent processing by the FCD 20. Alternatively, the signal conditioning circuitry may convert each FMD 10 signal into a corresponding analog output signal (e.g., a voltage signal) having a DC value proportional to the pulse frequency of the FMD 10 signal. Isolation circuits (not shown) within the SCD 15 may electrically isolate each FMD 10 from the other components of the system 5.
The FCD 20 receives the signals output by the SCD 15. With reference to FIG. 1b, the FCD 20 typically includes a microcontroller 35, a read-only memory (ROM) module 40, a random-access memory (RAM) module 45, an input/output (I/O) and display interface 50, and a communication module 55. The microcontroller 35 is configured to execute a set of firmware instructions stored within the ROM module 40 for computing real-time flow data corresponding to each FMD 10 based on the signals received from the SCD 15. For example, where the signals output by the SCD 15 are discrete signals, the microcontroller 35 may determine a frequency and maintain a pulse count total for each in order to compute a flow rate and a flow total, respectively, for each FMD 10. Where the signals output by the SCD 15 are analog signals, the microcontroller 35 may generate digitized representations of each to compute corresponding flow rates and then integrate the flow rates to compute corresponding flow totals. Flow data may be communicated from the microcontroller 35 to the RAM module 45 for storage and subsequent access. Flow data may also be communicated from the microcontroller 35 and/or the RAM module 45 to the I/O and display interface 50 for localized viewing thereon. The I/O and display interface 50 further enables configuration data required for FCD 20 operation to be entered, stored to the RAM module 45, and selectively recalled and displayed as needed. The communication module 55 is in communication with the microcontroller 35 and configured to enable the transmission of flow data, configuration data, and other information from the microcontroller 35 to the host computer 30 of FIG. 1a via a communication link, typically a serial communication link. The communication module 55 is typically configured to support a proprietary serial communication protocol (e.g., the proprietary communication protocol developed by Auper Electronic Controls Inc.) using, for example, an RS-232 electrical interface (e.g., for a single FCD 20 configuration as shown in FIG. 1a) or an RS-422 electrical interface (e.g., for a multiple FCD 20 configuration as shown in FIG. 1c).
With reference to FIG. 1a, the host computer 30 is typically implemented as a personal computer, including an input device 60, such as a keyboard, and a display 65, such as a computer screen or monitor. The host computer 30 typically executes a software application, such as the Draft Manager software application available from Auper Electronic Controls Inc., for initiating the exchange of flow data with the FCD 20, and for processing the flow data to perform account and inventory reconciliation. Additionally, the software package enables the host computer 30 to initiate the exchange of other information, such as the configuration data, with the microcontroller 35 and/or the RAM module 45.
With reference to FIG. 1c, a plurality of flow meter subsystems 25 may be interconnected to define a primary flow meter network 70 for enabling the monitoring of multiple beverage dispensation systems operating at a common location (e.g., the beverage dispensation systems of refreshment stands within a sports stadium). A communication hub 75 coupled between the FCD 20 of each flow meter subsystem 25 and a host computer 30 routes exchanged information therebetween. As shown, the communication hub 75 and communication modules 55 are configured to communicate using a serial protocol and the RS-422 electrical interface. An RS-422/RS-232 converter (not shown) may be connected between the communication hub 75 and the host computer 30 for enabling electrical interface compatibility. A user of the host computer 30 may thus perform account and inventory reconciliation for each beverage dispensation system of the primary flow meter network 70.
With reference to FIG. 1d, a plurality of the primary flow meter networks 70 may be interconnected via a local area network (LAN) 80 to define a secondary flow meter network 85. The administrative host computer 90 may be in communication with the host computers 30 via a wide area network (WAN) 95 and/or the Internet. In addition to implementing software such as the Draft Manager software application, each host computer 30 may be configured as a server. Accordingly, the administrative host computer 90 may support a remote access utility for enabling its user to log on to each host computer 30 and remotely initiate an instance of the Draft Manager software application for each.
Although the above-discussed flow meter networks address some of the problems associated with monitoring beverage dispensation to an extent, they are generally not well-suited for enabling integrated management and monitoring of multiple beverage dispensation systems spread across one or more geographically diverse business enterprises (e.g., the beverage dispensation systems of multiple restaurant chains) in an efficient and cost-effective manner.
First, the flow meter networks are generally unable to provide a cumulative, real-time indication of flows and flow totals for multiple dispensation systems. With reference to FIG. 1d, for example, the host computers 30 are not configured to communicate received flow data to the administrative host computer 90 as it becomes available. Rather, a user of the administrative host computer 90 must typically log on to each host computer 30 individually, open a corresponding instance of the software application (e.g., the Draft Manager application), and view/control the application remotely. Accordingly, if the user wishes to access the applications of several different host computers 30 simultaneously, a dedicated instance of the software application must be opened on each host computer 30. The administrative host computer 90 thus merely functions as a terminal for viewing/controlling remotely-implemented applications on an individual basis and cannot integrate and/or process flow data from the various flow meter networks 70 to provide a cumulative, real-time indication of beverage dispensation.
Second, because each flow meter network typically operates as a stand-alone network that is more often than not associated with a single business enterprise (e.g., a restaurant chain), the level of integration is low. Additionally, the flow meter networks are not generally accessible to or operable with other external networks. Accordingly, business enterprises not directly affiliated with the various POS locations but nonetheless having a need to monitor the beverages dispensed at each (e.g., beverage manufacturers and distributors) cannot communicate with the flow meter networks in order to receive real-time flow data therefrom.
Third, software applications for use with the flow meter networks, such as the Draft Manager application, typically support only offline account reconciliation functionality, i.e., performing a non-real-time comparison between the amount of beverages dispensed and the amount of beverages sold. More advanced functionalities that might otherwise be desirable and/or necessary for managing and monitoring beverage dispensation on a network-wide basis, such as, for example, automated inventory control and real-time beverage consumption and sales monitoring, are not supported.
Fourth, each flow meter system within the flow meter networks is largely self-contained and requires the installation, configuration, and maintenance of at least one host computer 30 at each location. This in turn necessitates the training, coordination, and active involvement of personnel at each location, increasing installation and operation costs. Furthermore, in cases where the host computer 30 communicates with FCDs 20 utilizing the RS-232 protocol, the distance limitation imposed by the RS-232 communication standard frequently requires the host computer 30 to be placed in the same location as the FCD 20s (e.g., in a basement, storage room, etc.). Such locations generally do not provide a desirable or otherwise convenient setting for using the host computer 30 to perform account and inventory reconciliation tasks. Furthermore, the host computer 30, although capable of performing other computing tasks, is thus typically dedicated to a single use due to its inconvenient location. This further increases installation and operation costs.
Accordingly, there exists a need for a distributed flow meter network that enables integrated management and monitoring of multiple beverage dispensation systems spread across one or more geographically-diverse business enterprises in an efficient and cost-effective manner.